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A ROUTING PROTOCOL FOR GENERAL MOBILE AD HOC NETWORKS 

TECHNICAL FIELD OF THE INVENTION 
The present invention relates to mobile ad hoc networks, and more 
5 particularly to a routing protocol for use in mobile ad hoc networks with symmetric 
and/or asymmetric links which uses route discovery and table lookup mechanisms. 



BACKGROUND OF THE INVENTION 
The present invention relates to mobile ad hoc networks (MANETs). A 
10 mobile ad hoc network (MANET) is a collection of wireless mobile nodes 
dynamically forming a network without the use of any existing network 
infrastructure. In a MANET, there is no predetermined topology or central controller, 
and the MANET does not rely on a pre-existing fixed infrastructure, such as a wire- 
line backbone network or a base station. The responsibilities for organizing and 
15 controlling the network are distributed among the nodes themselves. The entire 
network is mobile, and the individual nodes are allowed to move at will relative to 
each other. Each mobile node in the MANET operates not only as a host but also as a 
router, as some pairs of nodes may not be able to communicate directly with each 
other and may require other nodes to relay packets. 
20 MANETs typically have one or more of the following characteristics: 

Mobility of nodes and dynamically changing topology. Nodes are free to 
move arbitrarily; thus, the network topology, which is typically multihop, may 
change randomly and rapidly at unpredictable times. 

Asymmetric (unidirectional) links. An asymmetric link is caused by 
25 interference, differing radio or antenna capabilities, or adjustment of transmission 
and reception parameters such as power. An asymmetric link allows transmission 
between nodes in one direction only, while a symmetric link allows bidirectional 
transmission between the linked nodes. 

Flat addressing. Nodes are unable to form a subnet or to have subnet 
30 addresses. 
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Energy-constrained operation. Some or all of the nodes in a MANET may 
rely on batteries for energy. For these nodes, power conservation is a critical design 
criterion. 

Wireless vulnerabilities and limited physical security. Mobile wireless 
networks are generally more prone to information and physical security threats than 
fixed, hardwired nets. 

MANETs can be used in military, rescue, and emergency applications, where 
e,ther there is no other wireless communication infrastructure present or such 
infrastructure cannot be used because of security, cost, or safety reasons. MANETs 
can also operate as robust and inexpensive alternatives or enhancements of cell- 
based mobile network infrastructures. 

Commercially, MANET technology may be used to extend the range of 
Wireless Local Area Network (WLAN) technology over multiple radio hops. 
Networks that cover areas of several square kilometers can be built from WLAN 
technologies such as HiperLAN and IEEE802.il. People and vehicles can thus be 
inter-networked in areas without a pre-existing communication infrastructure, or 
when the use of such infrastructure further requires extension by wireless means. On 
smaller scales, technologies such as Bluetooth™ (a radio interface using the 
2.45GHz Industrial, Scientific, and Medical (ISM) frequency band, mainly used to 
offer short-range (-10 meters) data transmission via low-cost radio frequency 
modules and low power consumption) can be exploited in interesting ways to build 
embedded wireless networks. These networks would have a combination of static 
and mobile nodes, which could be fielded without cabling and with minimal pre- 
eonfiguration. As computing and communication devices proliferate and the 
requirements of highly adaptive mobile networking technology increase, unforeseen 
uses of this technology are likely to emerge, particularly in the embedded systems 
and micro-networking fields. 

Traditionally, end user devices, such as host computers or telephones, attach 
to distributed networks at fixed locations. As a consequence, they are assigned 
addresses based on their location in a fixed network-addressing hierarchy and often 
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assume an identity equivalent to their address. This identity-location equivalence 
greatly simplifies routing in these systems, as a user's location does not change. 

In mobile ad hoc networks, on the other hand, the routing infrastructure can 
move along with the end devices. Thus, the infrastructure's routing topology can 
5 change, and the addressing within the topology can also change. Given this 
fundamental difference in the composition of the routing infrastructure in 
comparison to fixed infrastructure networks, much of the fixed infrastructure's 
control technology is no longer useful. The infrastructure's routing algorithms and, 
indeed, much of the networking suite must be reworked to function efficiently and 

10 effectively in this mobile environment. 

The MANET working group (http://www.ietf.org/html.charters/manet- 
charter.html) in the Internet Engineering Task Force's (IETF-http://www.ietf.org/) 
Routing Area is chartered to provide improved mobile routing and interface 
definition standards for use within the Internet Protocol suite. In so doing, it hopes to 

15 lay the foundation for an open, flexible and extensible architecture for MANET 
technology. The routing protocols proposed in the MANET working group are 
developed in the network layer, because an internetwork layer routing solution is 
important for the following exemplary reasons: end user and application pressure for 
seamless internetworking will continue regardless of the underlying infrastructure 

20 (fixed or mobile); the "physical media independence" features of the network layer 
are important to support mobile routing through heterogeneous wireless fabrics, i.e. 
where different wireless technologies are used at the physical layer; definition of 
some common routing approaches and interface definitions provides future 
flexibility, and also improves the cost effectiveness of deployed systems. 

25 Ad hoc On-Demand Distance Vector Routing (AODV) and Dynamic Source 

Routing (DSR) are two of the routing protocols which have been proposed in the 
IETF MANET working group. AODV and DSR both use an on-demand routing 
approach. The performance of on-demand routing approaches is superior to that of 
the table-driven routing approaches in ad hoc networks, as described in S.J. Lee et al, 

30 "A Simulation Study of Table-Driven and On-Demand Routing Protocols for Mobile 
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Ad Hoc Networks," IEEE Network, v.13, no. 4, pp. 48-54, July/August, 1999. With 
on-demand routing, when a route is needed, a routing protocol attempts to find a 
route for the current data communication session. On-demand routing does not 
require each node to continuously evaluate and maintain all the routes to every other 
node in the network, as required with table-driven routing, thus avoiding the need to 
frequently exchange state information, reducing the amount of update traffic, and 
conserving limited resources. 

AODV is based on a distance vector routing mechanism and uses a route 
table to find the next hop in the route. AODV assumes symmetric links in the ad hoc 
network and hence carniot work properly in ad hoc networks having asymmetric 
links. DSR is based on a source routing mechanism and can work in ad hoc network 
having asymmetric links. However, DSR requires that the entire route map be 
carried with each data packet in order for the packet to reach its destination 
Although DSR does not involve the route table lookup required by AODV, it 
15 nevertheless involves heavy routing overhead in each data packet. 

Since the links in mobile ad hoc networks that connect neighboring nodes 
cannot be guaranteed to be symmetric, as mentioned in the foregoing, efficient 
routing protocols for networks having asymmetric links are needed. 

Most existing ad hoc network routing protocols, such as AODV and 
20 Associativity-Based long-lived Routing (ABR), were designed for networks with 
symmetric links, and thus cannot be used effectively to establish routes in ad hoc 
networks having asymmetric links. Some existing ad hoc network routing protocols, 
for example DSR and Cluster Based Routing Protocol (CBRP), take into 
consideration the case of networks having asymmetric links, but they require each 
25 data packet to carry the entire route map to enable routing, resulting in excessively 
high overhead in every packet. 



•1 
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SUMMARY OF THE INVENTION 
The present invention provides an on-demand routing protocol based on both 
table look-up and route discovery mechanisms which is suitable for routing in 
mobile ad hoc networks with symmetric and/or asymmetric links. The present 
5 invention includes a routing protocol for a mobile ad hoc network having a plurality 
of nodes interconnected by symmetric and/or asymmetric links, each node being 
associated uniquely with a corresponding route table. The protocol comprises 
discovering a route for a data packet from a first node to a second node, routing the 
data packet through the discovered route based on information in each route table 
1 0 along the discovered route, and maintaining the route. 

In an embodiment of the routing protocol, the first node is a requesting 
source node and the second node is a neighbor node to the first node, and the 
discovering a route comprises checking a neighbor list. 

In an embodiment of the routing protocol, the discovering a route comprises 
15 checking a neighbor list, broadcasting a first route request packet (RREQ), and 
receiving a route reply packet (RREP). 

In an aspect of the embodiment, the first RREQ is received and modified by 
an intermediate node. 

In an aspect of the embodiment, the intermediate node checks a status of a 
20 flag in the first RREQ and adds a reverse route entry to the route table corresponding 
to the intermediate node when the flag indicates a reverse route exists to the first 
node. 

In an aspect of the embodiment, the intermediate node broadcasts the 
modified first RREQ. 

25 In an aspect of the embodiment, the second node forms the RREP and 

unicasts the RREP to a next hop node along the reverse route. 

In an aspect of the embodiment, the next hop node modifies the RREP and 
builds a forward route entry in the route table corresponding to the reverse route. 
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In an embodiment of the routing protocol, the discovering a route comprises 
checking a neighbor list, broadcasting a first route request packet (RREQ), and 
receiving a route reply packet (RREP) including discovered route information. 

In an aspect of the embodiment, the first RREQ is received and modified by 
an intermediate node. 

In an aspect of the embodiment, the intermediate node checks a status of a 
flag in the first RREQ and broadcasts the modified first RREQ when the status of the 
flag indicates a reverse route to the first node does not exist. 

In an aspect of the embodiment, the second node forms a RREP using the 
modified first RREQ and unicasts the RREP to a next hop node along an available 
route. 

In an aspect of the embodiment, the first node unicasts an activating data 
packet including the discovered route information to a node along the discovered 
route after receiving the RREP. 

In an aspect of the embodiment, the node builds a forward route entry in the 
route table corresponding to the node. 

In an embodiment of the routing protocol, the discovering a route comprises 
checking a neighbor list, broadcasting a first route request packet (RREQ), and 
receiving a second RREQ including discovered route information. 

In an aspect of the embodiment, the first RREQ is received and modified by 
an intermediate node. 

In an aspect of the embodiment, the intermediate node checks a status of a 
flag in the first RREQ and broadcasts the modified first RREQ when the status of the 
flag indicates a reverse route to the first node does not exist. 

In an aspect of the embodiment, the second node forms the second RREQ 
using the modified first RREQ and broadcasts the second RREQ. 

In an aspect of the embodiment, the first node unicasts an activating data 
packet including the discovered route information to a node along the discovered 
route after receiving the second RREQ. 
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In an aspect of the embodiment, the node builds a forward route entry in the 
route table corresponding to the node. 

In an embodiment of the routing protocol, the information includes a route 

entry. 

In an aspect of the embodiment, the route entry includes a timer and the route 
entry is erased when the timer expires. 

In an aspect of the embodiment, the timer is reset when the route entry is 
used to route the data packet. 

In an embodiment of the routing protocol, the maintaining the discovered 
route comprises determining that a next hop node is unreachable, transmitting link 
failure information to at least one upstream node, and erasing at least one route entry. 

In an aspect of the embodiment, the transmitting link failure information 
comprises unicasting an error packet to the at least one upstream node. 

In an aspect of the embodiment, the at least one upstream node modifies the 
error packet and unicasts the modified error packet. 

• In an aspect of the embodiment, the transmitting link failure information 
comprises broadcasting an error packet. 

In an aspect of the embodiment, the at least one upstream node modifies the 
error packet and broadcasts the modified error packet. 

In an embodiment or the routing protocol, the at least one upstream node 
erases the at least one route entry. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Embodiments of the invention will now be described by way of example with 

reference to the drawings in which: 

Figure la is a schematic diagram illustrating transmission of route request 

and route reply packets in an embodiment according to the present invention in an 

exemplary case where a reverse route exists. 
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Figure lb is a schematic diagram illustrating transmission of route request 
and route reply packets in an embodiment according to the present invention in an 
exemplary case where a reverse route does not exist. 

Figure 2 shows an exemplary embodiment of the routing protocol according 
to the present invention. 

Figure 3 is a schematic diagram illustrating route maintenance in an 
embodiment according to the present invention. 

Figure 4 shows an exemplary embodiment of the route maintenance 
mechanism according to the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 
The present invention provides an on-demand routing protocol based on both 
table look-up and route discovery mechanisms which is suitable for routing in 
mobile ad hoc networks with symmetric and/or asymmetric links. The routing 
protocol of the present invention can exploit available symmetric link features of a 
network to improve efficiency. Data packets are routed along a discovered route 
based on information in route tables at nodes along the discovered route, reducing 
data packet overhead in comparison to source routing mechanisms. 

The routing protocol according to the present invention builds a route on 
demand and works efficiently in ad hoc networks with symmetric and/or asymmetric 
links between nodes. Route information is recorded in a route discovery packet 
during a route discovery procedure. In the route discovery procedure, link state 
information relating to symmetric or asymmetric links is used to evaluate available 
reverse routes. When a route discovery packet reaches the destination node, a route 
reply message may be sent back to a source node via a reverse route, if one is 
available, or via some other route which needs to be found. After the route is 
established, data packets are routed according to route tables kept at the nodes along 
the route. As used herein, "reverse route" indicates a route from the destination node 
to the source node of a source, destination node pair, and "forward route" indicates a 
route from the source node to the destination node of the node pair. In addition, the 
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format of reverse and forward route entries in the route tables is identical. Data 
packets do not need to carry the entire route map with them as is the case with the 
DSR protocol. Route maintenance may be carried out by transmitting link failure 
information along previously established routes that incorporate the failed link. 
5 Each node in the network maintains a neighbor list that stores link state 

information indicating whether its neighbors can be heard and/or are reachable, that 
is whether the node can receive transmissions from or send transmissions to its 
neighbor nodes. Assuming that a node has N neighbors, the format of its neighbor 
list may be as shown, for example, in Table I: 
10 Table I 



Node 


Status 


Node_l 


Stat_l 






Node_N 


Stat_N 



In Table I, Nodejc indicates the Internet Protocol (IP) address of neighbor node x, 
where 1 x N. Statx provides link state information, i.e. the status, of the link 
connecting the node and a neighbor node x. Stat x can take on one of three values: 

15 forward, reverse, or bidirectional. Forward status indicates that the neighbor node x 
can receive packets sent by the node. Reverse status indicates that packets sent by 
the neighbor node x can be received by the node. Bidirectional status indicates that 
the neighbor node x can receive packets sent by the node and vice versa. If the status 
is bidirectional, then the link connecting the node to its neighbor node x is 

20 symmetric. Otherwise the link is asymmetric. 

The neighbor list can be built and updated through various mechanisms such 
as promiscuous listening, beacon messaging, explicit 3-way handshaking or through 
periodic Hello message exchanges, as is known in the art. 

In order for a data packet to be sent from a source node to a destination node, 

25 a transmission route must exist. If a node, by checking its neighbor list, determines 
that the destination node is a neighbor node, then it can send the data packet to the 
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destination node directly. If the destination node is not a neighbor, then a route must 
be d.scovered before the data packet can be sent to the destination node. 

The details of the route discovery and data packet routing mechanisms 
according to the present invention will now be described. 

In order to discover a route to the destination node, the source node transmits 
a route discovery packet, referred to as a route request packet (RREQ) by 
broadcasting to its neighbor nodes. This RREQ will be rebroadcast again throughout 
the network by intermediate nodes and finally be received by the destination node. 
In one embodiment, the format o f the RREQ is as shown in (1) below 
[iype|De S t_addr|Src_addr |Req_id [Flag | Route_info -[^555- 



0) 



In the RREQ (i), the various fields may be described as follows- Type 
identifies the packet (e.g., in this case Type = RREQ); Best addr indicates the IP 
address of the requested destination node; Src_addr indicates the IP address of the 
requesting (source) node; R eqJd fa a sequence number generated by the source node 
15 to prevent the processing of duplicate RREQs received by intermediate nodes 
through different paths; Flag indicates whether a node along a route can build a 
reverse route to the requesting source node. If all links connecting intermediate 
nodes along the route from the requesting source node to the node are symmetric 
then a reverse route can be built from the node to the requesting source node along' 
20 the route, in a direction from the node to the source node; Route info is a list of IP 
addresses of intermediate nodes along the RREQ propagation route, in the order in 
which the intermediate nodes receive the RREQ; the Option field may contain 
^covered route map information for the case where the requested destination node 
needs to discover a route to the requesting source in order to send a reply packet as 
25 described further below. 

When a node receives a RREQ, it first checks the Src addr and Reg id 
values to avoid rebroadcasting duplicate RREQs. The node records Src addr and 
Reajd values for each RREQ for the purpose of comparing RREQs. A~duplicate 
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RREQ (a RREQ with Srcjaddr and Reqjd values identical to a previously received 
RREQ) is discarded by the node. 

If a node is not the requested destination node, then it modifies the RREQ 
appropriately, as described in the following. The node adds its own address to the 
5 sequence of addresses Route Jnfo in the RREQ. Furthermore, the node checks the 
Flag status. If Flag has been set to 1 , which means that no reverse route can be built 
from the upstream node (as determined from the last address in the Route Jnfo field 
in the packet) to the requesting source node, then the Flag statiis is left unchanged. 
If Flag has been set to 0 and the link connecting the node and the upstream node is 

10 symmetric, signifying that a reverse route can be built from the node to the 
requesting source node, then the Flag status is left unchanged. Otherwise, if Flag 
has been set to 0 and the link connecting the node and the upstream node is 
asymmetric, signifying that the node can receive directly a packet sent by the 
upstream node while the upstream node cannot receive directly a packet sent by the 

15 node (i.e., the packet must travel from the node to the upstream node by a circuitous 
route), then the node will set Flag to 1 . If Flag remains at 0, the node adds a reverse 
route entry to its route table. 

Each node in the network is associated with its own route table. An 
exemplary form of a route table is shown in Table II, where it is understood that the 

20 empty cells in the table are filled with valid values. Each row in the route table is 
referred to hereinafter as a "route entry" or simply "entry." 



Table II 



Dest addr 



Nxt_hp_addr 



Up_str_addr |Hop_cnt 



Time_stmp 



The various fields in Table II, indicated by the headings in the first row of 
Table II, contain the following data. A reverse route is built from a current node to 
the requesting source node. Dest_addr holds an address of the destination node to 
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which the packet will be sent ultimately. Here, it is filled with the address of the 
requesting source node (Src^ddr in the corresponding RREQ). Nxt_hp addr holds 
an address of the next hop node, to which the packet will be sent immediately. Here 
Nxt_hp_addr contains the address of the upstream node, obtained from Route info 
Up^tr_addr holds an address of the upstream node from which the packet is 
receded. Up_str_addr can be extended to form a list containing more than one 
upstream node address. Here, V P _str_addr holds the address of the node to which 
the RREQ may be sent . (This fidd fa ^ ^ ^ & 

route ,s built, and used in route maintenance in order for the node to be able to 
inform its upstream node of a failed link.) Ho P _cnt holds a number of hops from the 
current node to the destination node. Here, Moment contains the hop count from the 
current node to the requesting source node, derived from Route info. Time_st mp 
holds a time value. Here, Time_stm P contains the current time. Because ofnode 
mobility, a discovered route may become stale after some time. Thus, each entry or 
row in a route table is kept only for a short period of time in order to prevent a stale 
route from being used. The Time_stm P in each entry is periodically compared with 
the current time, and if the difference is more than a given value, then the 
corresponding entry is deleted from the route table. 

After modifying the RREQ by adding the current node address in the 
Route Jnfo field and adjusting the value of Flag in the RREQ, the current node 
broadcasts the modified RREQ. 

If a node is the requested destination node, the node forms a route reply 
packet (RREP) and sends it back to the requesting source node. If a reverse route 
from the requested destination node to the requesting source node is available, the 
RREP will be sent along the reverse route. Otherwise, the RREP will be sent along 
an available route to the requesting source node, or the destination node will find a 
new route through the route discovery procedure and piggyback the discovered route 
information on another RREQ, as described in greater detail hereinafter. Figure la 
illustrates the propagation of the RREP and RREQs in an exemplary case where a 
reverse route exists, /.*., when Flag = 0: the RREP travels along the same path that 
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the RREQ traversed. Figure lb illustrates the propagation of the RREP and RREQ 
in an exemplary case where a reverse route does not exist, i.e., when Flag =1: the 
RREP cannot travel along the path that the RREQ traversed, and a different route 
must be used. In Figures la and lb, a circle indicates a node in a mobile ad hoc 
5 network, a dashed line or dashed arrow indicates a link between two nodes, and a 
solid arrow represents a RREP and/or RREQ. 

Referring to Figure la, a route is established through the propagation of a 
RREQ 110 from source node 100 through intermediate node 102 to destination node 
101. Since a reverse route exists, the destination node 101 unicasts a RREP 120 

10 along the reverse route (through node 102) back to the source node 100. Each node 
along the reverse route, e.g. 102, examines the RREP 120, completes the reverse 
route entry by filling the immediate sender's address in the Up_str_addr field in the 
reverse route entry in the route table, and builds a forward route entry in the route 
table leading to the requested destination node. Thus, the RREP 120 does not need 

1 5 to carry the entire route map. 

An exemplary format of a RREP according to the present invention is shown 
in (2) below: 



Type 


Dest_addr 


Src_addr 


Hop _cnt 



20 The various fields in the RREP contain the following data: Destjzddr, the 

address of the requesting source node (Srcjaddr in the corresponding RREQ); 
Srcjaddr, the address of the requested destination node (Destjaddr in the 
corresponding RREQ); and Hopjcnt, the hop count from the requested destination 
node, initially set to zero at the requested destination address. 

25 The RREP is unicast to the node, e.g. 102 in Fig. la, having the address 

indicated in Nxtjtpaddr field in the reverse route entry. When the next hop node 
(102 in this example) receives the RREP, it gets the immediate sender's address (the 
address of node 101) and places it in the Upjstrjaddr field in its corresponding 
reverse route entry. This Upjstrjiddr value will be used in the route maintenance 
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procedure described below to inform upstream nodes of unavailable link status The 
next hop node (102 in this example) also builds a forward route entry in its route 
table leading to the requested destination node (node 101, in this example) The 
forward route entry has the same format as a reverse route entry, as shown for 
example, in Table III below, where it is understood that the empty cells in the table 
are to be filled with valid values. 



Table III 



10 



15 



20 



Dest_addr 


Nxt_hp_addr 


Up_str_addr 


Hop_cnt 


Time__stmp 























The various fields in Table III, indicated by the headings in the first row 
thereof, contain the following data: Dest__addr, the address of the requested 
destmation node (Src_addr in the RREP); N XtJl p_addr, the address of the previous 
node (from which the RREP was received); Up_str_addr, the Nxt hp addr in the 
corresponding reverse route entry; Hop_cnt, the hop count, obtained from the RREP; 
and Time_stmp, the current time. 

A node which receives a RREP will modify the RREP by increasing the 
value of Hop_cnt by one and re-send the RREP to its next hop node along the 
reverse route. In the example above, node 102 receives RREP 120, which has 
Hop_cnt = 0, set by destination node 101. Node 102 increases the value of Hop_cnt 
to 1 and re-sends RREP 120 to node 100, its next hop node along the reverse route 
When the RREP finally reaches the requesting source node along the reverse route 
(node 100 in the example above), a forward route from the requesting source node to 
the requested destination node is discovered accordingly. 

In the case where a reverse route does not exist, for example as shown in 
25 Figure lb, we consider two scenarios. In the first scenario, another existing route is 
avaxlable and may be used. In the second scenario, there is no available route and 
the previously discovered route information can be piggybacked on another RREQ to 
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the requesting source node. Turning to the first scenario, where another route is 
known and available, for example from requested destination node 151 to source 
node 150 through node 153, node 151 extracts Route Jnfo from the RREQ 160, 
forms a RREP 170 in response to the RREQ, and unicasts it to the requesting source 
5 node along the available route through 153 to 150. In contrast to the case discussed 
previously and shown in Figure la, in this case, the RREP does carry discovered 
route information. The RREP 170 in this case may have the format shown in (3) 
below, where the field Extracted Route Jnfo contains information extracted from the 
Route Jnfo field of the RREQ 160: 

10 



Type 


Dest_addr 


Src_addr 


Extracted Route_info 



In the second scenario, where an alternate route is not known, the destination 
node 151 inserts the appropriate Route Jnfo value into the Option field in a RREQ 
170 and sends it to the requesting source node 150 by broadcasting, that is, the 
15 discovered route map "piggybacks" on the RREQ 170. The format of the RREQ 170 
in this instance is the same as in (1) and is shown in (4) below: 



Type 


Dest_addr 


Src_addr 


Req_id 


Flag 


Route info 


Option 



When the requesting source node 150 retrieves the information from the 
20 Option field in RREQ 170 having the format (4), it knows the entire route map 
leading to the requested destination node 151. 

In the first and second scenarios described above, after the RREP or RREQ is 
received by the requesting source node, data packets can be routed to the destination 
node by using the Loose Source and Record Route option in IPv4 or the route header 
25 option in IPv6. (The Loose Source and Record Route option in IPv4 provides a 
means for the source of a packet to supply routing information to be used by 
intermediate nodes in forwarding the packet to the destination and to record the route 
information. The route header option in IPv6 allows the source of a packet to list the 



10 
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intermediate nodes to be "visited" on the way to a packet's destination.) In order to 
avoid carrying an entire route map with each data packet, the first data packet sent by 
the source node serves as an activating route packet to enable the nodes along the 
discovered route to build route entries in their route tables. This is in contrast to the 
scenario in which a reverse route exists (Figure la), wherein, as previously 
described, the forward route is built along the discovered route as the RREp 
propagates from the requested destination node to the source node, and consequently 
no activating packet is required. Based on the routing information in the Loose 
Source and Route Record option or the route header option in the data packet, each 
intermediate node along the route, e.g. 152 in Figure lb, is able to build a forward 
route entry in its route table. The fields in the forward route entry, such as 
Up_str_addr, N Xt _hp_addr and Hp_cnt, can be filled by examining the route 
information carried in the option header of the data packet. Thus, a forward route 
from the requesting source node, e.g. 150, through 152 to the requested destination 
node 151 can be established. 

If more than one RREQ is rece ived at the destination node, one of the routes 
in the RREQs may be chosen based on certain metrics (such as number of hops, 
signal strength, existence of reverse route, etc.). 

When route information is set in the route tables of the nodes along a route, 
subsequent data packets are routed to the destination node based on the data in the' 
route tables held by each node without the need to carry the entire route map in the 
subsequent data packets. 

When a first node needs to communicate with a second (destination) node, it 
first checks whether a route to the second node exists in its routing table. If a route 
does not exist, the first node broadcasts a RREQ to find a route to the destination 
node. If a route does exist from the first node to the destination node, the first node 
sends a data packet to the intended destination node based on route table information 
held by intermediate nodes. Each intermediate node along the route forwards the 
packet based on its route table. 
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Figure 2 provides an overview of an exemplary embodiment of the protocol 
according to the present invention. At 200, the requesting source node broadcasts a 
first RREQ. At 202, a node receiving the first RREQ determines whether it is the 
requested destination node. If the receiving node is not the destination node, at 204 
5 the receiving node verifies that the received first RREQ is not a duplicate, as 
described previously. At 206 the receiving node adds its own address to the first 
RREQ and at 208 checks the flag status to determine whether a reverse route to the 
requesting source node exists. If not, the receiving node broadcasts the modified 
first RREQ. If yes, the receiving node at 210 builds a reverse route entry in its route 

1 0 table and broadcasts the modified first RREQ. 

If the receiving node is the requested destination node, at 212 the receiving 
node forms a RREP and at 214 checks the flag status in the previously received first 
RREQ to determine whether a reverse route exists to the requesting source node. If 
yes, at 216 the destination node unicasts the RREP to its next hop node along the 

1 5 reverse route. At 2 1 8 the next hop node completes the reverse route entry in its route 
table, as described previously, and builds a forward route entry in its route table at 
220. At 222 the next hop node determines whether it is the requesting source node. 
If yes, route discovery is complete (224). If not, the next hop node unicasts the 
modified RREP to the next hop node along the reverse route. 

20 If the receiving node is not the requested destination node, at 226 the 

destination node determines whether an available route exists the requesting source 
node. If yes, the destination node forms a RREP containing information regarding 
the discovered route, as described previously (228) and unicasts the data packet to a 
node along the available route (230). At 232, if the node receiving the data packet is 

25 not the requesting source node, the receiving node unicasts the RREP to another 
node along the route. If the requesting source node receives this RREP, it unicasts 
an activating data packet (242). At 244, a node receiving this activating packet 
determines whether it is the requested destination node. If the receiving node is not 
the destination node, at 246 the receiving node builds a forward route entry in its 
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route table and unicasts the activating packet. If the receiving node is the destination 
node, route discovery is complete (248). 

If at 226 the destination node determines that an available route to the 
requesting source node does not exist, the destination node forms a second RREQ 
5 (236) containing information regarding the discovered route, as described previously 
and broadcasts the second RREQ (238). At 240, a node receiving the second RREQ 
determines whether it is the requesting source node by examining the RREQ as 
described previously. If the receiving node is not the requesting source node, 'the 
receiving node rebroadcasts the second RREQ. If the requesting source node 
10 receives the second RREQ, it unicasts an activating data packet (242), which is 
treated as described in the preceeding paragraph and shown in Figure 2. A route 
maintenance mechanism according to the present invention will now be described 
When a current node notices, using, for example, one or more of the mechanisms 
hsted previously for building up the neighbor list, that the next hop node along a 
15 route is unreachable, it must notify the upstream nodes using the route to update the 
route information held by each intermediate node in a timely manner. In this 
circumstance, the current node sends an error packet to the upstream node indicated 
by the corresponding route entry in its route table to inform the upstream node that 
the destination node is unreachable. Two different ways to send the error packet are 
20 considered below. 

First, if there exists a reverse route or other available route to the upstream 
node from the current node, then the current node unicasts an error packet to the 
upstream node. The format of the error packet may be as shown in (5) below: 



25 



| Type | Dest_addr | Src_addr | Route_DestJdd7~] 



(5) 



The various fields in the error packet having the format shown in (5) contain 
the following data: Dest_addr, the address of the upstream node in the relevant 
route; Srcridr, the address of the current node, which is forming the error packet- 
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Route _Dest_addr 9 the address of the destination node in the relevant route; and Type, 
an indication that the packet is a unicast route error packet. 

When the upstream node receives the error packet, it erases the route entry 
(Le. row) in its route table where the values in the fields Nxtjipjzddr and Destaddr 
5 in the route entry match the values in the Srcjxddr and Route Destjzddr fields in 
the error packet, respectively, and sends a similar error packet to its next upstream 
node. 

The following example illustrates the functioning of route maintenance 
according to the present invention, in the exemplary case where two routes have been 

10 discovered in the mobile ad hoc network. Figure 3 diagrammatically illustrates the 
case where source node 300 has discovered a route to destination node 306 
consisting of, in sequence, nodes 300, 301, 305, 302, and 306, while source node 303 
has discovered a route to the same destination node 306 consisting of nodes 303, 
304, 305, 302 and 306. In Figure 3, a circle indicates a node, in a mobile ad hoc 

15 network, a bold line with arrowheads at both ends indicates a symmetric link 
between two nodes, and a regular line with an arrowhead at only one end indicates an 
asymmetric link between two nodes. 

Tables IVa, IVb, and IVc are route tables built in nodes 301, 304, and 305, 
respectively, where valid entries in the Time_stmp fields are represented by the 

20 symbol *. (The exact values are not critical to this discussion.) 



Table IVa (node 301) 



Dest_addr 


Nxt_hp_addr 


Up_str_addr 


Hop_cnt 


Timestmp 


300 


300 


305 


1 


* 


306 


305 


300 


3 


* 
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Table IVb (node 304) 



Dest_addr 


Nxt_hp_addr 


Up_str_addr 


Hop_cnt 


Timestmp 


306 


305 


303 


3 


* 


303 


303 




1 


• 













Table IVc (node 305) 



Dest_addr 


Nxt_hp_addr 


Up_str_addr 


Hop_cnt 


Time stmp 


300 


301 


302 


! 2 


* 


306 


302 


301 


2 


* 


306 


302 


304 


2 


* 



If node 305 notices the node 302 is unreachable, it informs the related 
upstream nodes about the broken link, that is, node 305 sends an error packet to 
nodes 301 and nodes 304 in the concerned routes. 

We first consider the case in which a reverse route back to the source node is 
available. A similar procedure would be followed in the case where there exists an 
available route which is not the reverse route. In this case, node 305 erases the route 
entry (6) in Table IVc: 



306 


302 


30J 


2 


* 



(6). 



Node 305 also sends an error packet (7) to node 301: 



| Type 


301 


305 


306 



(7) 



When node 301 receives the error packet (7), because the values in both the 
Nxt_hp_addr and Dest_addr fields in its route table (Table IVa), 305 and 306, 
respectively, match the Src_addr and Route _Dest_addr values in the error packet,' 
node 301 erases the following route entry in Table IVa: 
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306 


305 


300 


3 


* 



(8) 



Node 301 also sends an error packet (9) to node 300: 



Type 


300 


301 


306 



(9) 



10 



Finally, the source node 300 receives the error packet (9) and erases the 
relevant route entry in its route table. 

We next consider the case in which no route is available from a current node 
to an upstream node. In this case, the current node sends an error packet to the 
upstream node by broadcasting. The format of the broadcast error packet (10) may 
be as shown below: 



Type 


Dest_addr 


Src_addr 


Errid 


Route_Dest_addr 



(10) 



The Dest_addr y Srcjxddr, and Route JDestjaddr fields have the same 
significance in the error packet (10) as in the error packet (5). The Errjd field holds 

15 a sequence number set by the node corresponding to the Src_addr. Errjd is 
combined with Srcaddr to prevent a node from broadcasting a duplicate error 
packet. (As a result no node will process the same error packet twice.) The Type 
field indicates that the packet (10) is a broadcasting route error packet. 

When the upstream node receives the error packet (10), it erases the route 

20 entry in its own route table in which the values in the Nxtjipjxddr and Destjaddr 
fields match those in the Srcjxddr and Route _Dest_addr fields of the error packet 
(10), rebuilds the error packet by placing the address of an upstream node address in 
the Destaddr field, placing its own node address in the Src addr field, and 
choosing an Err jd, and rebroadcasts the rebuilt error packet. 

25 When, in the above example, node 305 notices that the node 302 is 

unreachable, it erases the following route entry in node 305: 



f 



10 
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306 


302 


304 


2 


* 1 



(11) 



Node 305 also informs its upstream node 304 about the unavailable route to 
node 306. Since there is no available route to node 304 (the link from node 304 to 
node 305 being asymmetric), it will broadcast the error packet (12): 



Type 


304 


305 


Err_id 


306 1 



(12) 



The error packet (12) is rebroadcast through nodes 301, 300, and 303 to reach 
node 304. 

When node 304 receives the packet (12), because the Nxt_hp_addr and 
Dest_addr values in its route table (Table IVb), 305 and 306, respectively, match the 
Src_addr and Route _Dest_addr values in the packet, it erases following route entry 
in Table IVb: 



15 



306 



305 



303 



(13) 



Node 304 also sends an error packet (14) to node 303: 



20 



25 



Type 


303 


304 


Err_id 


306 | 



(14) 



It should be understood that the value of Err_id changes each time the error packet is 
rebuilt. Finally, the source node 303 receives this error packet and is thereby 
informed of the defective route. 

Figure 4 provides an overview of an exemplary embodiment of the route 
maintenance mechanism according to the present invention. At 400, a node 
determines that a next hop node in a route is unreachable, as described previously. 
At 402, the node determines whether a route is available to an upstream node in the 
route. If an available route exists at 402, then at 404, the node erases a route entry 
containing information regarding the failed link, forms an error packet (406), and 
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unicasts the error packet to an upstream node along the available route (408). The 
upstream node erases a route entry containing information regarding the failed link 
(410). The upstream node then determines by examining the error packet whether it 
is the requesting source node for the route containing the failed link (412). If the 
5 upstream node is not the' source node, it modifies the error packet, as described 
previously (414) and unicasts the modified error packet. If the upstream node is the 
source node, all nodes in the route have been alerted to the failed link, and route 
maintenance is complete (416). 

If an available route does not exist at 402, then the node forms an error packet 

10 (418) and broadcasts the error packet (420). If a node receiving the error packet is 
not the upstream node (422), it rebroadcasts the error packet (420). If the node is the 
upstream node, it erases a route entry containing information regarding the failed 
link (424). The upstream node determines by examining the received error packet 
whether it is the requesting source node for the route containing the failed link (426). 

15 If the receiving node is not the source node, it modifies the error packet (428) and 
broadcasts the modified error packet (420). If the upstream node is the source node, 
route maintenance is complete (430). 

The routing protocol of the present invention has a number of advantages 
over the prior art. For example, the routing protocol according to the present 

20 invention is on-demand in nature and carries all the advantages of on-demand 
routing protocols compared to table driven protocols, since no periodic route table 
information exchange is required. The routing protocol of the present invention is 
also capable of supporting ad hoc networks having asymmetric links. This 
functionality is achieved without adding packet overhead, as in the case of protocols 

25 relying on source routing mechanisms, such as DSR. The present invention requires 
only minimal routing information in each data packet, as does AODV, but, unlike 
AODV, works properly in ad hoc networks having asymmetric links. It also 
provides reverse route formation with explicit link status. In addition, node neighbor 
discovery eliminates the need to carry out route discovery in the case of destinations 

30 that are neighbors. Moreover, since a single pair of RREQ and RREPs may be used, 
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modified as appropriate by intermediate nodes as the packets propagate through the 
network, a larger number of nodes are able to derive partial or complete route 
information, since explicit route and link status are known to the nodes. 
Furthermore, the route maintenance algorithm of the present invention minimizes the 
number of stale routes. 

Various preferred embodiments of the invention have now been described. 
While these embodiments have been set forth by way of example, various other 
embodiments and modifications will be apparent to those skilled in the art. 
Accordingly, it should be understood that the invention is not limited to such 
embodiments, but encompasses all that which is described in the following claims. 
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What is claimed is: 

1 . A routing protocol for a mobile ad hoc network having a plurality of nodes 
interconnected by symmetric and/or asymmetric links, each node being associated 

5 uniquely with a corresponding route table, the protocol comprising: 

discovering a route for a data packet from a first node to a second node; 
routing the data packet through the discovered route based on information 
in each route table along the discovered route; and 
maintaining the route. 

10 

2. The routing protocol according to claim 1, wherein the first node is a 
requesting source node and the second node is a neighbor node to the first node, 
and the discovering a route comprises checking a neighbor list. 

15 3. The routing protocol according to claim 1, wherein the discovering a route 
comprises: 

checking a neighbor list; 

broadcasting a first route request packet (RREQ); and 
receiving a route reply packet (RREP). 

20 

4. The routing protocol according to claim 3, wherein the first RREQ is 
received and modified by an intermediate node. 

5. The routing protocol according to claim 4, wherein the intermediate node 
25 checks a status of a flag in the first RREQ and adds a reverse route entry to the 

route table corresponding to the intermediate node when the flag indicates a reverse 
route exists to the first node. 

6. The routing protocol according to claim 5, wherein the intermediate node 
30 broadcasts the modified first RREQ. 
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7. The routing protocol according to claim 5, wherein the second node forms 
the RREP and unicasts the RREP to a next hop node along the reverse route. 

8. The routing protocol according to claim 7, wherein the next hop node 
5 modifies the RREP and builds a forward route entry in the route table 

corresponding to the reverse route. 

9. The routing protocol according to claim 1, wherein the discovering a route 
comprises: 

10 checking a neighbor list; 

broadcasting a first route request packet (RREQ); and 

receiving a route reply packet (RREP) including discovered route 
information. 

15 10. The routing protocol according to claim 1, wherein the first RREQ is 
received and modified by an intermediate node. 

11. The routing protocol according to claim 10, wherein the intermediate node 
checks a status of a flag in the first RREQ and broadcasts the modified first RREQ 

20 when the status of the flag indicates a reverse route to the first node does not exist. 

12. The routing protocol according to claim 10, wherein the second node forms 
the RREP using the modified first RREQ and unicasts the RREP to a next hop 
node along an available route. 



25 



13. 



The routing protocol according to claim 12, wherein the first node unicasts 
an activating data packet including the discovered route information to a node 
along the discovered route after receiving the RREP. 

30 14. The routing protocol according to claim 13, wherein the node builds a 
forward route entry in the route table corresponding to the discovered route. 



WO 02/084956 PCT/SGO 1/00064 

27 

15. The routing protocol according to claim 1, wherein the discovering a route 
comprises: 

checking a neighbor list; 

broadcasting a first route request packet (RREQ); and 
5 receiving a second RREQ including discovered route information. 

16. The routing protocol according to claim 15, wherein the first RREQ is 
received and modified by an intermediate node. 

10 17. The routing protocol according to claim 16, wherein the intermediate node 
checks a status of a flag in the first RREQ and broadcasts the modified first RREQ 
when the status of the flag indicates a reverse route to the first node does not exist. 

18. The routing protocol according to claim 16, wherein the second node forms 
15 the second RREQ using the modified first RREQ and broadcasts the second 

RREQ. 

19. The routing protocol according to claim 18, wherein the first node unicasts 
an activating data packet including the discovered route information to a node 

20 along the discovered route after receiving the second RREQ. 

20. The routing protocol according to claim 19, wherein the node builds a 
forward route entry in the route table corresponding to the discovered route. 



25 21. The routing protocol according to claim 1, wherein the information 
includes a route entry. 

22. The routing protocol according to claim 21, wherein the route entry 
includes a timer and the route entry is erased when the timer expires. 

30 

23. The routing protocol according to claim 22, wherein the timer is reset when 
the route entry is used to route the data packet. 
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24. The routing protocol according to claim 1, wherein the maintaining the 
discovered route comprises: 

determining that a next hop node is unreachable; 
5 transmitting link failure information to at least one upstream node; and 

erasing at least one route entry. 

25. The routing protocol according to claim 24, wherein the transmitting link 
failure information comprises unicasting an error packet to the at least one 

10 upstream node. 



20 



26. The routing protocol according to claim 25, wherein the at least 
upstream node modifies the error packet and unicasts the modified error packet. 



one 



15 27. The routing protocol according to claim 26, wherein the transmitting link 
failure information comprises broadcasting an error packet. 

28. The routing protocol according to claim 27, wherein the at least one 
upstream node modifies the error packet and broadcasts the modified error packet. 



29. The routing protocol according to claim 24, wherein the at least one 
upstream node erases the at least one route entry. 
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